<p>The highest Value is the slowest and highest quality mode. In comparison to value of 5, value of 6 usually gains 0.1-0.4 dB global PSNR with speed costs varying from 25%-100%. Unlike other levels of subq , the behavior of value of 6 does not depend much on frameref and me . Instead, the effectiveness of value of 6 depends mostly upon the number of B-frames used. In normal usage, this means value of 6 has a large impact on both speed and quality in complex, high motion scenes, but it may not have much effect in low-motion scenes. Note that it is still recommended to always set bframes to something other than zero.</p>
<p>Merely raising the value to 2 gains around 0.15dB PSNR with a 5-10% speed penalty; this seems like a good tradeoff. value of 3 gains around 0.25dB PSNR over value of 1 , which should be a visible difference. Value of 3 is around 15% slower than value of 1 . Unfortunately, diminishing returns set in rapidly. Value of 6 can be expected to gain only 0.05-0.1 dB over value of 3 at an additional 15% speed penalty. Above value of 6 , the quality gains are usually very small. In a fairly typical case, value of 12 will improve global PSNR by a tiny 0.02dB over value of 6 , at a speed cost of 15%-20%.</p>
<p> This option is for choosing the motion estimation search method. Altering this option provides a straightforward quality-vs-speed tradeoff. me= dia is only a few percent faster than the default search, at a cost of under 0.1dB global PSNR. Hexagon Search is a reasonable tradeoff between speed and quality. Uneven Multi-hexagon gains a little under 0.1dB global PSNR, with a speed penalty that varies depending on frameref . At high values of frameref (e.g. 12 or so), Uneven Multi-hexagon is about 40% slower than the Hexagon Search. With frameref=3 , the speed penalty incurred drops to 25%-30%. </p>
<p> </p></td>
</tr>
<tr valign="top">
<td width="138">8x4, 4x8 and 4x4 subpartitions</td>
<p>This option enables the use of 8x4, 4x8 and 4x4 subpartitions in predicted macroblocks (in addition to the default partitions). Enabling it results in a fairly consistent 10%-15% loss of speed. This option is rather useless in source containing only low motion, however in some high-motion source, particularly source with lots of small moving objects, gains of about 0.1dB can be expected.</p>
<p>In H.264, B-frames are useful: there are new techniques and block types that are possible in B-frames. Usually, even a naive B-frame choice algorithm can have a significant PSNR benefit. It is interesting to note that using B-frames usually speeds up the second pass somewhat, and may also speed up a single pass encode if adaptive B-frame decision is turned off. </p>
<p> With adaptive B-frame decision turned off, the optimal value for this setting is usually no more than 1 , or else high-motion scenes can suffer. With adaptive B-frame decision on, it is safe to use higher values; the encoder will reduce the use of B-frames in scenes where they would hurt compression. The encoder rarely chooses to use more than 3 or 4 B-frames; setting this option any higher will have little effect. </p>
<p>With this option enabled, the encoder will use a reasonably fast decision process to reduce the number of B-frames used in scenes that might not benefit from them as much. You can use b_bias to tweak how B-frame-happy the encoder is. The speed penalty of adaptive B-frames is currently rather modest, but so is the potential quality gain. It usually does not hurt, however. Note that this only affects speed and frametype decision on the first pass. b_adapt and b_bias have no effect on subsequent passes. </p>
<p>You might as well enable this option if you are using >=2 B-frames; as the man page says, you get a little quality improvement at no speed cost. </p>
<p>In typical cases, there is not much gain with this option. However, in crossfades or fade-to-black scenes, weighted prediction gives rather large bitrate savings. In MPEG-4 ASP, a fade-to-black is usually best coded as a series of expensive I-frames; using weighted prediction in B-frames makes it possible to turn at least some of these into much smaller B-frames. Encoding time cost is minimal, as no extra decisions need to be made. Also, contrary to what some people seem to guess, the decoder CPU requirements are not much affected by weighted prediction, all else being equal. <br/>
Unfortunately, the current adaptive B-frame decision algorithm has a strong tendency to avoid B-frames during fades. Until this changes, it may be a good idea to turn off B-frame Decision, if you expect fades to have a large effect in your particular video clip. </p>
<p>This trades off the number of bits allocated to "expensive" high-motion versus "cheap" low-motion frames. At one extreme, value of 0 aims for true constant bitrate. Typically this would make high-motion scenes look completely awful, while low-motion scenes would probably look absolutely perfect, but would also use many times more bitrate than they would need in order to look merely excellent. At the other extreme, value of 100 achieves nearly constant quantization parameter (QP). Constant QP does not look bad, but most people think it is more reasonable to shave some bitrate off of the extremely expensive scenes (where the loss of quality is not as noticeable) and reallocate it to the scenes that are easier to encode at excellent quality.</p>
<p>This setting is solely for trading off file seekability against coding efficiency. Value of 250, in 25fps material, this guarantees the ability to seek to within 10 seconds precision. If you think it would be important and useful to be able to seek within 5 seconds of precision, set it to 125 ; this will hurt quality/bitrate slightly. If you care only about quality and not about seekability, you can set it to much higher values. The video stream will still have seekable points as long as there are some scene changes.</p></td>
